Method and System for Exchange of Value or Tokens Between Blockchain Networks

ABSTRACT

A blockchain value transfer method including receiving a plurality of transaction requests, performing a balance check procedure on each transaction request to determining if the transaction value in first in-network tokens is greater than the present permitted transaction amount of the sending user account address, adding the transaction request to an aggregate transaction record, determining a net transaction amount for each user account address for each transaction in the aggregate transaction record, with the transaction value for transactions including the user account address as the sending user account address as a debit and as the receiving user account address as a credit, and executing the net transaction amount for each user account address associated with the net transaction amount by transacting tokens to and from the user account addresses upon reaching an aggregation threshold.

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. § 119(e) of U.S.Provisional Patent Application Ser. No. 62/818,798 filed on Mar. 15,2019 and titled A Use Case Extension to the Value Token TransferProtocol (VTTP) and is a continuation-in-part application of and claimspriority under 35 U.S.C. § 120 of U.S. patent application Ser. No.15/976,910 (Attorney Docket No. 3026.00008) filed on May 11, 2018 andtitled Method and System for Exchange of Value or Tokens BetweenBlockchain Networks, which in turn claims priority under 35 U.S.C. §119(e) of U.S. Provisional Patent Application Ser. No. 62/652,341 filedon Apr. 4, 2018 and titled Value Token Transfer Protocol—VTTP. Thecontents of these applications are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to Value Token Transfer Protocol (VTTP), aprotocol for exchange of value or tokens within and between blockchainnetworks.

BACKGROUND OF THE INVENTION

Blockchain is a distributed and public ledger which maintains records ofall the transactions. A blockchain network is a truly peer-to-peernetwork and it does not require a trusted central authority orintermediaries to authenticate or to settle the transactions or tocontrol the network infrastructure. Users can interact and transact withthe blockchain networks through Externally Owned Account (EOAs), whichare owned and controlled by the users. Each EOA has a balance (incertain units of a Cryptocurrency associated with the Blockchainnetwork) associated with it. EOAs do not have any associated code. Alltransactions on a blockchain network are initiated by EOAs. Theseaccounts can send transactions to other EOAs or contract accounts.Another type of accounts support by second generation programmableBlockchain platforms are the Contract Accounts. A Contract Account iscreated and owned by an EOA and is controlled by the associated contractcode which is stored with the account. The contract code execution istriggered by transactions sent by EOAs or messages sent by othercontracts.

Blockchain networks can either be public or private. Public blockchainnetworks are free and open to all and any user can create an account andparticipate in the consensus mechanism on a public blockchain and viewall the transactions on the network. Private blockchain networks areusually controlled and operated by a single organization and thetransactions can be viewed only by the users within the organization.Public blockchain networks are usually unpermissioned or permissionless,as any node can participate in consensus process. Some public blockchainnetworks adopt a permissioned model where the consensus process iscontrolled by a pre-selected set of nodes. Private blockchain networksusually adopt the permissioned model. While public blockchain networkscan be considered as fully decentralized, private blockchain networksare partially decentralized.

Organizations can have multiple private blockchain networks where eachnetwork is dedicated to a specific use case or department or businessvertical. The blockchain networks within an organization may be createdeither using the same blockchain platform or technology or withdifferent platforms or technologies.

On each blockchain network, a user can create multiple Externally OwnedAccounts (EOAs). Each Externally Owned Account (EOA) has apublic-private keypair associated with it. The account address isderived from the public key. When a new EOA is created, a keyfile iscreated which has the public and private keys associated with theaccount. The private key is encrypted with the password which isprovided while creating the account. For sending transactions to otheraccounts, the private key and the account password are required.

This background information is provided to reveal information believedby the applicant to be of possible relevance to the present invention.No admission is necessarily intended, nor should be construed, that anyof the preceding information constitutes prior art against the presentinvention.

SUMMARY OF THE INVENTION

With the above in mind, embodiments of the present invention aredirected to a system and associated methods for exchange of value ortokens within and between blockchain networks.

In some embodiments, the method may further comprise a Value TokenTransfer Protocol (VTTP) that provides the following features:

-   -   Intra-chain value transfer of native cryptocurrency (e.g. ETH on        Ethereum blockchain);    -   Intra-chain value transfer of ERC20 tokens (e.g. sending OMG        tokens and receiving SNT tokens);    -   Inter-chain value transfer of cryptocurrencies (e.g. Send ETH        from Ethereum blockchain and receive LTC on Litecoin        blockchain);    -   Intra and Inter-chain exchange of cryptocurrencies and ERC20        tokens (e.g. send BAT token from Ethereum blockchain and receive        LTC on Litecoin blockchain); and    -   Retrieve information on accounts, contracts, transactions for        all participating blockchain networks.

In some embodiments, the method may further comprise client-server modelin which VTTP works as a request-response protocol based on aclient-server architecture, where a VTTP Client sends requests to a VTTPServer, and the server responds to the requests.

In some embodiments, the method may further comprise a peer-to-peermodel in which VTTP works as a peer-to-peer protocol where VTTP Peerscommunicate directly with their peers and a VTTP Coordinator may be usedfor coordinating the communication between peers.

VTTP is blockchain platform or network independent. VTTP can be used tosend any type of tokens between different blockchain networks or withina blockchain network, as long as the VTTP client and server know how tointerpret and transfer tokens.

VTTP is a stateless protocol. Each VTTP request contains all theinformation required to process a request. VTTP client and server do notmaintain state between successive requests.

Further embodiments may be directed to a blockchain value transfermethod comprising receiving a plurality of transaction requests, eachtransaction request comprising a sending user account address, areceiving user account address, and a transaction value expressed interms of a quantity of first in-network tokens, the user accountaddresses being addresses on a blockchain network. The method furthercomprises performing a balance check procedure on each transactionrequest comprising identifying a present permitted transaction amount infirst in-network tokens for the sending user account address, anddetermining if the transaction value in first in-network tokens isgreater than the present permitted transaction amount of the sendinguser account address. Upon determining the transaction value in firstin-network tokens is greater than the present permitted transactionamount in first in-network tokens of the sending user account address,the method may continue with refusing the transaction. Upon determiningthe transaction value is not greater than the present permittedtransaction amount of the sending user account address, the method maycontinue with adding the transaction request to an aggregate transactionrecord, updating the present permitted transaction amount of the sendinguser account address reflecting a debit of the transaction value, andupdating the present permitted transaction amount of the receiving useraccount address reflecting a credit of the transaction value. The methodmay further comprise determining a net transaction amount for each useraccount address for each transaction in the aggregate transactionrecord, with the transaction value for transactions including the useraccount address as the sending user account address as a debit and asthe receiving user account address as a credit and executing the nettransaction amount for each user account address associated with the nettransaction amount by transacting tokens to and from the user accountaddresses upon reaching an aggregation threshold, comprising withdrawingan amount of tokens from user account addresses with a net debit havinga value equal to the value of the net debit, defined as debit useraccount addresses, defining debited tokens and depositing an amount oftokens from the debited tokens to user account addresses with a netcredit in an amount equal to the amount of the net credit, defined ascredit user account addresses.

In some embodiments, execution of the net transaction amount maycomprise recording a net transaction smart contract to the blockchainnetwork, the net transaction smart contract comprising each of the useraccount addresses and the tokens transacted with each of the useraccount addresses. Furthermore, the net transaction smart contract mayadd a transaction fee to each token transaction for the user accountaddresses.

In some embodiments, the aggregation threshold may be defined as atleast one of a length of time elapsing since a previous net transactionexecution, a gross transaction amount, or a risk tolerance.

In some embodiments, each transaction request of the plurality oftransaction requests may have an associated transaction request smartcontract recorded on the blockchain network, defining a plurality oftransaction request smart contracts. Each transaction request smartcontract may comprise a transaction tax added to the transaction value.

In some embodiments, the method may further comprise, for each refusedtransaction, re-determining if the transaction value in first in-networktokens is greater than the present permitted transaction amount of thesending user account address after at least one of a first time intervaland an intervening transaction involving the sending user accountaddress, defining a transaction retry, for one or more of a fixed numberof transaction retry attempts or after a second time interval.

In some embodiments, the method may further comprise a first sendinguser account address of a first transaction request of the plurality oftransaction requests is on a first blockchain network comprising thefirst in-network token, a first receiving user account address of thefirst transaction request is on a second blockchain network andcomprises a second in-network token, and the first receiving useraccount address is determined to be a credit user account address.Executing the net transaction amount for the receiving user account mayfurther comprise exchanging an amount of first in-network tokens, equalin value to the net credit for the first receiving user account,defining a net credit value, for an amount of first tethered tokenshaving a value equal to the net credit value, the first tethered tokensbeing comprised by a first tethered token transfer record, recording atransaction to the first blockchain network of sending the firsttethered token transfer record from the first blockchain network to thesecond blockchain network, recording a transaction to the secondblockchain network of receiving the first tethered token transfer recordat the second blockchain network from the first blockchain network,exchanging the first tethered tokens comprised by the first tetheredtransfer record for an amount of second in-network tokens having a valueequal to the net credit value, defining a second blockchain networkdeposit, and depositing the second blockchain network deposit to thereceiving user account address. Furthermore, the first tethered tokenmay have a value thereof tethered to a first fiat currency, the firstin-network token may have a first exchange rate with the first tetheredtoken, and the second in-network token may have a second exchange ratewith the first tethered token that is different from the first exchangerate.

In some embodiments, a first sending user account address of a firsttransaction request of the plurality of transaction requests may be on afirst blockchain network comprising the first in-network token, a firstreceiving user account address of the first transaction request may beon a second blockchain network and comprises a second in-network token,and the first receiving user account address may be determined to be acredit user account address. Executing the net transaction amount forthe receiving user account may comprise exchanging an amount of firstin-network tokens, equal in value to the net credit for the firstreceiving user account, defining a net credit value, for an amount offirst tethered tokens having a value equal to the net credit value, thefirst tethered tokens being comprised by a first tethered token transferrecord, recording a transaction to the first blockchain network ofsending the first tethered token transfer record from the firstblockchain network to a tethered token exchange, exchanging the firsttethered tokens comprised by the first tethered token transfer recordfor an amount of second tethered tokens having a value equal to the netcredit value, the second tethered tokens being comprised by a secondtethered token transfer record, recording a transaction to the secondblockchain network of receiving the second tethered token transferrecord at the second blockchain network from the tethered tokenexchange, exchanging the second tethered tokens comprised by the secondtethered transfer record for an amount of second in-network tokenshaving a value equal to the net credit value, defining a secondblockchain network deposit, and depositing the second blockchain networkdeposit to the receiving user account address. A value of the firsttethered token may be tethered to a first fiat currency, a value of thesecond tethered token may be tethered to a second fiat currencydifferent from the first fiat currency, the first in-network token mayhave a first exchange rate with the first tethered token, the secondin-network token may have a second exchange rate with the secondtethered token, and the first tethered token may have a third exchangerate with the second tethered token. The method may further comprise atleast one of defining the first exchange rate responsive, the secondexchange rate, and the third exchange rate responsive to the second fiatcurrency. The method may further comprise updating the present permittedtransaction amount responsive to at least one of the first fiat currencyand the second fiat currency.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of the blockchain account types andinteractions.

FIG. 2 is an illustration of the TCP/UDP/IP reference model layers withthe VTTP protocol as part of the application layer, according to anembodiment of the invention.

FIG. 3 is an illustration of the VTTP components, according to anembodiment of the invention.

FIG. 4 is an illustration of the VTTP client-server model, according toan embodiment of the invention.

FIG. 5 is an illustration the VTTP peer-to-peer model, according to anembodiment of the invention.

FIG. 6 is an illustration of the VTTP intra-chain value transferprocess, according to an embodiment of the invention.

FIG. 7 is an illustration of the VTTP inter-chain value transferprocess, according to an embodiment of the invention.

FIG. 8 is an illustration the VTTP commands, according to an embodimentof the invention.

FIG. 9 is an illustration the transaction signing process in VTTP,according to an embodiment of the invention.

FIG. 10 is an illustration of the token-based authentication process inVTTP, according to an embodiment of the invention.

FIG. 11 is an illustration of the two-factor authentication process inVTTP, according to an embodiment of the invention.

FIG. 12 is an illustration of VTTP Secure (VTTPS), a secure version ofVTTP that runs over SSL/TLS, according to an embodiment of theinvention.

FIG. 13 is an illustration the multi-signature transaction signingprocess in VTTP, according to an embodiment of the invention.

FIG. 14 is an illustration an exemplary VTTP server architecture,according to an embodiment of the invention.

FIG. 15 is an illustration an exemplary VTTP reference architecture,according to an embodiment of the invention.

FIG. 16 is an illustration of VTTP status codes, according to anembodiment of the invention.

FIG. 17 is an illustration of the TCP/UDP/IP reference model layers withthe VTTP+ protocol as part of the application layer, according to anembodiment of the invention.

FIG. 18 is an illustration of the VTTP+ components, according to anembodiment of the invention.

FIG. 19 is an illustration of a VTTP+ client-server model, according toan embodiment of the invention.

FIG. 20 is an illustration a VTTP+ peer-to-peer model, according to anembodiment of the invention.

FIG. 21 is an illustration of a VTTP+ intra-entity value transferprocess, according to an embodiment of the invention.

FIG. 22 is an illustration of a VTTP+ inter-entity value transferprocess, according to an embodiment of the invention.

FIG. 23 is an illustration of an exemplary VTTP+ server architecture,according to an embodiment of the invention.

FIG. 24 is an illustration of an exemplary VTTP+ reference architecture,according to an embodiment of the invention.

FIG. 25 is an illustration of an exemplary scenario of value transferbetween two networks which use common universal tether tokens, accordingto an embodiment of the invention.

FIG. 26 is an illustration of an exemplary scenario of value transferbetween two networks which use different tether tokens, according to anembodiment of the invention.

FIG. 27 is an illustration of an exemplary scenario of aggregationtransactions of in-network tokens, according to an embodiment of theinvention.

FIG. 28 is an illustration of an exemplary scenario of aggregation oftransactions across two blockchain networks utilizing respective firstand second in-network tokens, according to an embodiment of theinvention.

FIG. 29 is an illustration of the result of an exemplary scenario ofaggregation of transactions across two token networks, according to anembodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention will now be described more fully hereinafter withreference to the accompanying drawings, in which preferred embodimentsof the invention are shown. This invention may, however, be embodied inmany different forms and should not be construed as limited to theembodiments set forth herein. Rather, these embodiments are provided sothat this disclosure will be thorough and complete, and will fullyconvey the scope of the invention to those skilled in the art. Those ofordinary skill in the art realize that the following descriptions of theembodiments of the present invention are illustrative and are notintended to be limiting in any way. Other embodiments of the presentinvention will readily suggest themselves to such skilled persons havingthe benefit of this disclosure. Like numbers refer to like elementsthroughout.

Although the following detailed description contains many specifics forthe purposes of illustration, anyone of ordinary skill in the art willappreciate that many variations and alterations to the following detailsare within the scope of the invention. Accordingly, the followingembodiments of the invention are set forth without any loss ofgenerality to, and without imposing limitations upon, the claimedinvention.

In this detailed description of the present invention, a person skilledin the art should note that directional terms, such as “above,” “below,”“upper,” “lower,” and other like terms are used for the convenience ofthe reader in reference to the drawings. Also, a person skilled in theart should notice this description may contain other terminology toconvey position, orientation, and direction without departing from theprinciples of the present invention.

Furthermore, in this detailed description, a person skilled in the artshould note that quantitative qualifying terms such as “generally,”“substantially,” “mostly,” and other terms are used, in general, to meanthat the referred to object, characteristic, or quality constitutes amajority of the subject of the reference. The meaning of any of theseterms is dependent upon the context within which it is used, and themeaning may be expressly modified.

Various types of computing hardware may be disclosed herein, e.g.server, computer, computerized device, smart phone, etc. Except wheredescribed otherwise, it is contemplated and included within the scope ofthe invention that such hardware may comprise a processor operable toexecute software resulting in a described function, a memory devicepositioned in communication with the processor permitting the storage ofsoftware thereon as well as data generated or processed by theprocessor, and a communication device positioned in communication withthe processor and, in some embodiments, the memory device, and isoperable to send and receive data across any type of computer network asis known in the art. The memory device may be permanent andnon-transitory.

Referring now to FIG. 1, for example, and without limitation, blockchainaccount types and interactions between them, are described in moredetail. Blockchain is a distributed and public ledger which maintainsrecords of all the transactions. A blockchain network 100 is a trulypeer-to-peer network and it does not require a trusted central authorityor intermediaries to authenticate or to settle the transactions or tocontrol the network infrastructure. Users can interact and transact withthe blockchain networks through Externally Owned Account (EOAs) 110,which are owned and controlled by the users. Each EOA 110 has an accountaddress 102, account public-private keys 104 and a balance 106 (incertain units of a Cryptocurrency associated with the Blockchainnetwork) associated with it. EOAs do not have any associated code. Alltransactions 120 on a blockchain network are initiated by EOAs. Theseaccounts can send transactions to other EOAs or contract accounts.Another type of accounts support by second generation programmableBlockchain platforms are the Contract Accounts 108. A Contract Account108 is created and owned by an EOA 110, is located at a contract address112, and is controlled by the associated contract code 114 which isstored with the contract account 108. Additionally, the contract account108 may comprise a balance 116, which may be identical to the balance106 of the EOA 110. The contract code 114 execution is triggered bytransactions 118 sent by EOAs or messages sent by other contracts.

Referring now to FIG. 2, the TCP/IP reference model layers with the VTTPprotocol 150 as part of an application layer 154, is described in moredetail. VTTP 150 is an application layer protocol and works alongsideHypertext Transfer Protocol (HTTP) 152 and on top of a transport layer156 executing Transmission Control Protocol (TCP) 157 and an Internetlayer 158 executing Internet Protocol (IP) 159. While TCP isspecifically recited, all other transport layer protocols as are knownin the art are contemplated and included within the scope of theinvention, including, but not limited to, User Datagram Protocol (UDP),SCTP (Stream Controlled Transfer Protocol), and Quick UDP InternetConnections (QUIC). Additionally, while VTTP may operate over theInternet, it is contemplated and included within the scope of theinvention that VTTP may operate over any Wide Area Network (WAN), LocalArea Network (LAN), Personal Area Network (PAN), cellular network, andthe like. Additionally, any communication medium is contemplated andincluded within the scope of the invention, including, but not limitedto, Ethernet, fiber optical communication, cable communication, wirelesscommunication (including radio, visible light, microwave, and any otherelectromagnetic transmission) such as IEEE 802xx standards, and anyother telecommunication standard, method, or medium. Moreover VTTP maybe implemented on devices operating configured to communicate with otherdevices, i.e., the Internet of Things (IoT).

Referring now to FIG. 3, the components of the Value Token TransferProtocol (VTTP), are described in more detail. In one embodiment, VTTPworks as a request-response protocol based on a client-serverarchitecture, where a VTTP client 200 sends requests to a VTTP Server212, and the server responds to the requests. The VTTP clients 200 maybe available for different platforms and devices such as a desktopclient 204, a mobile client 206 or an embedded client 208. Users 202send VTTP requests to the VTTP server 212 using VTTP clients 200. VTTPrequests contain VTTP commands 210 which are processed by the VTTPserver 212. A VTTP server 212 may have one or more VTTP Workers 214 toprocess VTTP requests and execute the VTTP commands 210 sent by VTTPclients 200. VTTP server 212 has blockchain clients 216 for each of theparticipating blockchain networks 220, 222, 224.

A separate blockchain network 218 may be used for user identity andaccess management. The identity information of each user may bemaintained on a separate blockchain network. An identity verificationand certification procedure is performed for securely linking blockchainaccounts to real users. The identity (and associated blockchainaccounts) of each user may be separately verified through an identityverification process. A system and associated methods for securelylinking blockchain accounts to real users, as described in related U.S.patent application Ser. No. 15/863,128 titled Method and System forBlockchain-Based Combined Identity, Ownership and Custody Managementfiled Jan. 5, 2018, the content of which is incorporated herein byreference except to the extent disclosure therein is inconsistent withdisclosure herein. A user identity registration and certificationprocedure is performed that comprises receiving hashed useridentification information that has been signed with a private key ofthe user from the user, defining a seal contract, generating an addressof the seal contract, defined as a sealed user record address, andproviding the sealed user record address. The procedure may furthercomprise receiving a hashed verification record from a certificateauthority, generating an address of a verification contract from thehashed verification record, defined as a sealed verification recordaddress and providing the sealed verification record address.Furthermore, the procedure may further comprise generating acertification contract from a combination of the sealed user recordaddress, a certification token, and the sealed verification recordaddress, providing a certification contract address, receiving averification record by a certification authority comprising the hasheduser identification information and a token, and receiving a combinationof the certification contract address and the seal contract, defining areceived certification contract address and a received seal contract,respectively. Additionally, the procedure may further comprise obtainingeach of the sealed user record address and the sealed verificationrecord address from the certification contract address, retrieving theseal contract from the sealed user record address, defining a retrievedseal contract, decrypting the retrieved seal contract using a public keyassociated with the user, defining a decrypted retrieved seal contract,and comparing the decrypted retrieved seal contract and the receivedseal contract. Yet further, the procedure may comprise retrieving theverification contract from the sealed verification record address,defining a retrieved verification contract, obtaining a certificationtoken from the certification contract address, generating a hashedconfirming verification record by hashing the combination of thedecrypted retrieved seal contract and the certification token, andcomparing the hashed confirming verification record to the retrievedverification contract. Upon a comparison of the decrypted retrieved sealcontract and the received seal contract indicating they are at least apartial match and the comparison of the hashed confirming verificationrecord to the retrieved verification contract indicating they are atleast a partial match, a session certification token for a decentralizedapplication may be generated. Finally, the procedure may comprisetransmitting the session certification token to the user.

Referring now to FIG. 4, the VTTP client-server model, is described inmore detail. In the client-server model, VTTP works as arequest-response protocol based on a client-server architecture, whereVTTP clients 250, 256, 260, 264 send requests to a VTTP server 258, andthe server responds to the requests. The server processes the VTTPrequests and generates and sends transactions to the participatingblockchain networks 268, 270 to execute a value transfer.

Referring now to FIG. 5, the VTTP peer-to-peer model, is described inmore detail. In the peer-to-peer model, VTTP works as a peer-to-peerprotocol where VTTP peers 300, 306, 310, 314, operated by respectiveusers 302, 304, 312, 316, communicate directly with their peers and aVTTP coordinator 308 may be used for coordinating the communicationbetween peers. VTTP peers 300, 306, 310, 314 generate and sendtransactions to the participating blockchain networks 268, 270 toexecute a value transfer on blockchain networks 318, 320.

Referring now to FIG. 6, the VTTP intra-chain value transfer process, isdescribed in more detail. The VTTP intra-chain value transfer processenables transfer of cryptocurrency or tokens from one account to anotheraccount on the same blockchain network. For example, consider anintra-chain value transfer request where a User A 354 wants to transfercertain units of a cryptocurrency or tokens from an account on ablockchain network 374 to the account of another User B 358 on the sameblockchain network. At step 1 356, User A 354 initiates value transferrequest to send cryptocurrency or tokens to User B 358 (e.g. to send 1ETH from user A to user B). At step 2 360, the VTTP client 350 sends aVTTP SEND request to the VTTP server 370. At step 3 362, the VTTP servergenerates a raw transaction and returns the same in SEND response. Atstep 4 364, User A signs the raw transaction with the private key andVTTP client 350 sends the VTTP SIGN transaction. At step 5 372, VTTPserver 370 verifies the signature and broadcasts the transaction to theblockchain network 374. At step 6 366, User A 354 receives a valuetransfer notification. At step 7 368, User B 358 receives a valuetransfer notification via VTTP Client 352.

Referring now to FIG. 7, the VTTP inter-chain value transfer process, isdescribed in more detail. The VTTP inter-chain value transfer processenables transfer of cryptocurrency or tokens from an account on ablockchain network to another account on a different blockchain network.At step 1 408, User A 404 initiates a cross chain value transfer requestto User B 406 (e.g. to send 1 ETH from user A to user B who receives thevalue in equivalent number of LTC). At step 2 410, VTTP client 400 sendsa VTTP SEND request to the VTTP server 418. At step 3 434, VTTP servergenerates a raw transaction and returns the same in SEND response. Inthis raw transaction the ‘from’ field is user A's account, and ‘to’field is a ‘Vault Account’ on blockchain network-1 430. At step 4 412,User A 404 signs the raw transaction with the private key and VTTPclient 400 sends the VTTP SIGN transaction. At step 5 426, VTTP server418 verifies the signature and broadcasts the transaction to theblockchain network-1 430. At step 6 422, when the value transfer fromUser A account to Vault account on blockchain network-1 430 isconfirmed, the cryptocurrency and tokens are sent to aCryptocurrency/Token Exchange account 420. At step 7 424, cyptocurrencyor tokens are exchanged. At step 8 428, the exchanged cyptocurrency ortokens are sent to User B account on blockchain network-2 432. At step 9414, User A 404 receives a value transfer notification. At step 10 416,User B 406 receives a value transfer notification via VTTP Client 402.

Referring now to FIG. 8, VTTP commands are described in more detail. TheVTTP GET command 452 is used to retrieve information about an account,contract, transaction, and an exchange rate for a token. For example,the VTTP GET command 452 to retrieve balance of an account may look asfollows:

GETvttp://ROOT_URL/ethereum/address/0x004E1A8B6d1B65C2497055e65AFC5E5A46Db750D/balance

The VTTP SEND command 454 is used to send value from one account toanother account in same network. For example, the VTTP SEND command 454to send ETH from one Ethereum account to another may look as follows:

SENDvttp://ROOT_URL/ethereum?from=0x004E1A8B6d1B65C2497055e65AFC5E5A46Db750D&to=0x0049b1258Fd75C021d99E2109323Daa0E9ae8a6A&value=1

A VTTP SEND command 454 to send ERC20 token ABC from account A andreceive ERC20 token XYZ in account B may look as follows:

SENDvttp://ROOT_URL/ethereum?from=0x004E1A8B6d1B65C2497055e65AFC5E5A46Db750D&to=0x0049b1258Fd75C021d99E2109323Daa0E9ae8a6A&source=ABC&destination=XYZ&&sourceContract=0x4891615e2942FD4c176E4f2Ae3faF281E26EE466

&destinationContract=0x2fF2159D77805d489F6347BbEa3067Efb13d3176&value=1

The VTTP XSEND command 456 is used to send value from one account toanother account in another network. For example, the VTTP XSEND command456 to send ETH from an Ethereum account and receive LTC in a Litecoinaccount may look as follows:

XSEND vttp://ROOT_URL/ethereum/litecoin?from=0x004E1A8B6d1B65C2497055e65AFC5E5A46Db750D&to=LWhC2FmafKgDbqT129rB8Yj3dB9FVGhA2E&source=ETH&destination=LTCvalue=1

The VTTP REQUEST command 458 is used to request value from an account inthe same network. For example, the VTTP REQUEST command 458 to requestETH from an Ethereum account may look as follows:

REQUEST vttp://ROOT_URL/ethereum?from=0x004E1A8B6d1B65C2497055e65AFC5E5A46Db750D&to=0x0049b1258Fd75C021d99E2109323Daa0E9ae8a6A&value=1

The VTTP XREQUEST command 460 is used to request value from an accountin another network. For example, the VTTP XREQUEST command 460 torequest LTC from a Litecoin account and receive ETH in Ethereum accountmay look as follows:

XREQUEST vttp://ROOT_URL/ethereum/litecoin? from=0x004E1A8B6d1B65C2497055e65AFC5E5A46Db750D&to=LWhC2FmafKgDbqT129rB8Yj3dB9FVGhA2E&source=LTC&destination=ETH&value=1

The VTTP RESPOND command 462 is used to accept or deny a requestreceived from an account in the same network. For example, the VTTPRESPOND command 462 to accept a value transfer request within Ethereumnetwork may look as follows:

RESPOND vttp://ROOT_URL/ethereum?reqid=132376876 &status=accept

Similarly, the VTTP RESPOND command 462 to deny a value transfer requestwithin Ethereum network may look as follows:

RESPOND vttp://ROOT_URL/ethereum?reqid=132376876 &status=deny

The VTTP XRESPOND command 464 is used to accept or deny a requestreceived from an account in another network. For example, the VTTPXRESPOND command 464 to accept a value transfer request from Litecoin toEthereum network may look as follows:

XRESPOND vttp://ROOT_URL/ethereum/litecoin?reqid=63768237 &status=accept

Similarly, the VTTP XRESPOND command 464 to deny a value transferrequest from Litecoin to Ethereum network may look as follows:

XRESPOND vttp://ROOT_URL/ethereum/litecoin?reqid=63768237 &status=deny

The VTTP SIGN command 466 is used to sign and approve a transaction. Forexample, the VTTP SIGN command 466 to sign a value transfer request maylook as follows:

SIGN vttp://ROOT_URL/ethereum?Id=1827637&signature=0xf86b0184ee6b280082520894187

Referring now to FIG. 9, the transaction signing process in VTTP, isdescribed in more detail. VTTP transactions that transfer value aresigned and approved by the user on the client side. For example, to sendvalue from one account to another account within the same blockchainnetwork 504, the VTTP client 500 sends a VTTP SEND command at step 506.The VTTP server 502 generates the blockchain network 504 specific rawtransaction and returns the raw transaction in the response at step 508.The user then signs the raw transaction with the private key 514 andsends the signed transaction with the VTTP SIGN command at step 510. TheVTTP server 502 verifies the signature, broadcasts the signedtransaction at step 516 to the blockchain network 504, and sends a SIGNresponse at step 512. With this model of signing transactions on theclient side, the user can retain the private keys on the user's localmachine and need not share them with the VTTP server.

Referring now to FIG. 10, the token-based authentication process inVTTP, is described in more detail. A VTTP client 550 can authenticatewith a VTTP server 552 using an authentication token which is generatedby the client and verified by the VTTP server 552. VTTP may use existingauthentication token standards such as JSON Web Token (JWT) (describedin RFC 7519) for securely transmitting information between a client andserver as a JSON object. VTTP may also support other custom tokenstandards. An example of using JSON Web Token standard forauthenticating a VTTP client 550 with a VTTP server 552 is shown in FIG.10. At the client side, the username and password fields 554 arecombined and encrypted to generate an encrypted authentication string556. The VTTP client 550 sends a VTTP AUTH request to the VTTP server552 containing the encrypted authentication string 556 at step 560. TheVTTP server decrypts the encrypted authentication string 556 andverifies the user's credentials, and then generates a JSON Web token atstep 574. A JSON Web Token contains header, payload and signaturefields. The header field may specify the token type (JWT) and thesigning algorithm used (such as HMAC SHA-256 algorithm). The payloadfield may contain registered, private and public claims. The registeredclaims defined in JWT include claims such as ‘iss’ (issuer of thetoken), ‘sub’ (subject of the token), ‘aud’ (audience of the token),‘exp’ (token expiration time defined in Unix time), ‘nbf’ (‘not beforetime’ that identifies the time before which the JWT must not be acceptedfor processing), ‘iat’ (‘issued at’ time, in Unix time, at which thetoken was issued) and ‘jti’ (JWT ID). To create the signature part of aJSON Web Token the encoded header, the encoded payload, a secret, aresigned using the algorithm specified in the header. For example, if theHMAC SHA256 algorithm is used, the signature is created as follows:

HMACSHA256( base64UrlEncode(header) + “.” + base64UrlEncode(payload),secret)

The signature is also used to verify the message wasn't changed alongthe way. The VTTP server 552 returns a VTTP AUTH response 562 containingthe JSON Web Token. The VTTP client 550 uses this token for allsubsequent VTTP requests 564, 570, and the VTTP server 552 validates theauthentication token and process the VTTP requests 564, 570, thensending respective VTTP response 568, 572. When the JSON Web tokenexpires, the VTTP client 550 sends a new AUTH request.

Referring now to FIG. 11, the two-factor authentication process in VTTP,is described in more detail. VTTP supports two-factor authentication. Toauthenticate a VTTP client 600 with a VTTP server 602 when two-factorauthentication is enabled for a user's account, the client first sends aVTTP AUTH request 610 containing an encrypted authentication string. TheVTTP server 602 decrypts the authentication string and verifies theuser's credentials at step 628. If two-factor is enabled for user'saccount, the VTTP server 602 returns ‘is2FAEnabled’ as ‘True’ in theresponse 612. The VTTP client 600 then sends another AUTH request 614,containing the encrypted authentication string and a two-factorauthentication token. The VTTP server 602 decrypts and verifies user'scredentials and two-factor authentication token and generates JSON WebToken which is used as an authentication token for all subsequentrequests sent by the VTTP client 600 at step 630. The VTTP server 602returns a VTTP AUTH response containing the JSON Web Token at step 618.The VTTP client 600 uses this token for all subsequent VTTP requests620, 624, and the VTTP server 602 validates the authentication token andprocess the VTTP requests 620, 624, then sending respective VTTPresponse 622, 626.

Referring now to FIG. 12, VTTP Secure (VTTPS), a secure version of VTTPthat runs over SSL/TLS, is described in more detail. The use of SSL/TLSallows an encrypted channel of communication between the client andserver. A handshake process is done in which the client and servercompute a symmetric key which is used to encrypt all communicationduring their TLS session. At step 658, a VTTP client 650 initiates ahandshake by sending a Client Hello message to a VTTP server 654. Atstep 660, the VTTP server 654 responds with a Server Hello message andthe server's certificate. At step 656, the VTTP client 650 authenticatesthe server's identity by verifying the server certificate with acertificate authority 652. At step 662, the VTTP client 650 sends akey-info containing a random string of data to the server (which isencrypted with the server's public key). After this step the VTTP client650 and the VTTP server 654 each have the random string of data which isused to calculate (independently) the symmetric key that will be used toencrypt all remaining communication for the duration of that specificTLS session, such calculations being performed at steps 678 and 674,respectively. The VTTP client 650 and the VTTP server 654 then both sendrespective “Finished’ messages that have been encrypted with thesymmetric key at the end of the handshake at steps 664 and 666. Allsubsequent communication 668, 670 between the VTTP client 650 and theVTTP server 654 may be encrypted using the symmetric key.

Referring now to FIG. 13, the multi-signature (“multisig”) transactionsigning process in VTTP, is described in more detail. The FIG. 13 showsan example of using VTTP for a multisig contract that requires 2 out of3 signatures to process a transaction. At step 1 736, User A 732initiates value transfer request to send cryptocurrency or tokens. Atstep 2 714, VTTP client 712 sends a VTTP SEND request to the VTTP server702. At step 3 716, VTTP server 702 generates a raw transaction andreturns the same in SEND response. At step 4 718, User A 732 signs theraw transaction with the private key and VTTP client 712 sends the VTTPSIGN transaction. At step 728, User A 732 may indicate the transactionID to other signatories to the contract or other signatories may get anotification from the VTTP server 702. At step 5 720, User B 710retrieves the transaction using the transaction ID. At step 6 722, VTTPserver 702 returns the raw transaction to be signed by User B 710. Atstep 7 724, User B 710 signs the raw transaction with the private keyand VTTP client 700 sends the VTTP SIGN transaction. At step 8 726, VTTPserver 702 verifies the signatures of User A 732 and User B 710 andbroadcasts the transaction to a blockchain network 708.

Referring now to FIG. 14, an exemplary VTTP server architecture, isdescribed in more detail. A VTTP server 750 may have one or more VTTPWorkers 752 to process VTTP requests and execute the VTTP commands sentby VTTP clients. VTTP server 750 has blockchain clients 764 for each ofthe participating blockchain networks 772, 774, 776. A separateblockchain network 770 may be used for user identity and accessmanagement. The VTTP server 750 may contain additional services, such asUser Identity & Access Management Service 760, Authentication &Authorization Service 758, and Analytics & Reporting Service 762. TheVTTP server 750 may contain inter- and intra-blockchain messagingservices 766 and connectors for databases, cloud services & blockchainnetworks 768. A transactions filter 754 may be used in the server tofilter transactions. The server may use various Smart Contracts 756 tobolster security. These smart contracts may be executed for each VTTPrequest and perform additional verification (such as verifying senderand receiver's address). The smart contracts may enforce checks such astime limits or quantity restrictions. Some smart contracts may performfunctions similar to virus filters, for filtering out suspicioustransactions. New smart contracts can be distributed to VTTP servers ina manner similar to virus updates.

Referring now to FIG. 15, an exemplary VTTP reference architecture, isdescribed in more detail. Users 800 may use VTTP clients 802, 806 tocommunicate with VTTP servers 810, 812, 814 through an API gateway 804.The VTTP servers 810, 812, 814 sit under a load balancer 808 and exposea number API endpoints. The API gateway 804 makes these APIs availableto the VTTP clients. Each API has an endpoint (for example,vttp://example.com/ethereum) and a set of VTTP methods or commands whichare supported for the endpoint (such as GET, SEND, REQUEST, etc.). TheAPI gateway 804 may use an API key to enable authentication for APIs.The API gateway 804 may also perform additional functions such aslogging each API request and rate-limiting of requests. A separaterelational (SQL) or non-relational (NoSQL) database 816 may be used tostore data such as user credentials and application specific data. EachVTTP server is connected to all the participating blockchain networks818, 820.

Referring now to FIG. 16, VTTP status codes 850 are described in moredetail. The status code ‘1xx’ 852 is used to signal that a request hasbeen received. For example, a value transfer request is received and isbeing processed. The status code ‘2xx’ 854 is used to signal that arequested action has been successfully completed. The status code ‘3xx’856 is used to signal that a VTTP command has been accepted, but therequested action is being held in abeyance, pending receipt of furtherinformation. The status code ‘4xx’ 858 is used to signal that a VTTPcommand was not accepted due to a client error and the requested actiondid not take place. The status code ‘5xx’ 860 is used to signal that aVTTP command was not accepted due to a server error and the requestedaction did not take place.

A further embodiment of the invention may be referred to as a VTTP+protocol. The VTTP+ protocol may be understood to build upon the VTTPprotocol, including facilitating transactions from user devices, such assmart phones. Referring now to FIG. 17, TCP/IP reference model layerscomprised by a VTTP+ protocol 1004 as part of an application layer 1006,is described in more detail. VTTP+ 1004 is an application layer protocoland works alongside Hypertext Transfer Protocol (HTTP) 1000 and VTTPprotocol 1002 and on top of a transport layer 1008 executing TCP 1010and UDP 1012 protocols, which are in turn on top of an Internet layer1014 executing Internet Protocol (IP) 1016. While TCP and UDP arespecifically recited, all other transport layer protocols as are knownin the art are contemplated and included within the scope of theinvention, including, but not limited to, SCTP (Stream ControlledTransfer Protocol), and Quick UDP Internet Connections (QUIC).Additionally, while VTTP+ may operate over the Internet, it iscontemplated and included within the scope of the invention that VTTP+may operate over any Wide Area Network (WAN), Local Area Network (LAN),Personal Area Network (PAN), cellular network, and the like.Additionally, any communication medium is contemplated and includedwithin the scope of the invention, including, but not limited to,Ethernet, fiber optical communication, cable communication, wirelesscommunication (including radio, visible light, microwave, and any otherelectromagnetic transmission) such as IEEE 802xx standards, and anyother telecommunication standard, method, or medium. Moreover VTTP+ maybe implemented on devices operating configured to communicate with otherdevices, i.e., the Internet of Things (IoT).

Referring now to FIG. 18, components of the VTTP+ protocol are describedin more detail. In the current embodiment, VTTP+ works as arequest-response protocol based on a client-server architecture, where aVTTP+ client 1100 sends requests to a VTTP+ Server 1110, and the server1110 responds to the requests. The VTTP+ clients 1100 may be availablefor different platforms and devices such as a desktop client 1104, amobile client 1106 or an embedded client 1108. Users 1102 send VTTP+requests to the VTTP+ server 1110 using VTTP+ clients 1100. VTTP+requests contain VTTP+ commands 1124 which are processed by the VTTP+server 1110. A VTTP+ server 1110 may have one or more VTTP+ Workers 1112to process VTTP+ requests and execute the VTTP+ commands 1124 sent byVTTP+ clients 1100. The VTTP+ server 1110 may provide a VTTP+ API 1114that allows the participating blockchain networks 1118, participatingfiat banks 1120 and participating fiat wallets 1122 to use VTTP+protocol for exchange of value 1126, 1128, 1130. The VTTP+ protocolsupports the following types of transactions:

-   -   VTTP+ supports exchange of fiat currency (in fiat bank accounts        and fiat wallet apps) with tokens on blockchain networks;    -   Fiat value transfer between fiat accounts of participating fiat        banks;    -   Fiat value transfer between wallet accounts of participating        fiat wallets;    -   Fiat value transfer between fiat accounts of participating fiat        banks and accounts of participating fiat wallets;    -   VTTP+ allows retrieving information on accounts, balances, and        transactions for all participating fiat bank accounts and fiat        wallets; and    -   VTTP+ allows retrieving information on accounts, balances,        contracts, transactions for all participating blockchain        networks.

A separate blockchain network 1116 may be used for user identity andaccess management. The identity information of each user may bemaintained on a separate blockchain network. An identity verificationand certification procedure is performed for securely linking blockchainaccounts to real users. The identity (and associated blockchainaccounts) of each user may be separately verified through an identityverification process. A system and associated methods for securelylinking blockchain accounts to real users, as described in related U.S.patent application Ser. No. 15/863,128 titled Method and System forBlockchain-Based Combined Identity, Ownership and Custody Managementfiled Jan. 5, 2018, the content of which is incorporated herein byreference except to the extent disclosure therein is inconsistent withdisclosure herein. A user identity registration and certificationprocedure may be performed, comprising receiving hashed useridentification information that has been signed with a private key ofthe user from the user, defining a seal contract, generating an addressof the seal contract, defined as a sealed user record address, andproviding the sealed user record address. The procedure may furthercomprise receiving a hashed verification record from a certificateauthority, generating an address of a verification contract from thehashed verification record, defined as a sealed verification recordaddress and providing the sealed verification record address.Furthermore, the procedure may further comprise generating acertification contract from a combination of the sealed user recordaddress, a certification token, and the sealed verification recordaddress, providing a certification contract address, receiving averification record by a certification authority comprising the hasheduser identification information and a token, and receiving a combinationof the certification contract address and the seal contract, defining areceived certification contract address and a received seal contract,respectively. Additionally, the procedure may further comprise obtainingeach of the sealed user record address and the sealed verificationrecord address from the certification contract address, retrieving theseal contract from the sealed user record address, defining a retrievedseal contract, decrypting the retrieved seal contract using a public keyassociated with the user, defining a decrypted retrieved seal contract,and comparing the decrypted retrieved seal contract and the receivedseal contract. Yet further, the procedure may comprise retrieving theverification contract from the sealed verification record address,defining a retrieved verification contract, obtaining a certificationtoken from the certification contract address, generating a hashedconfirming verification record by hashing the combination of thedecrypted retrieved seal contract and the certification token, andcomparing the hashed confirming verification record to the retrievedverification contract. Upon a comparison of the decrypted retrieved sealcontract and the received seal contract indicating they are at least apartial match and the comparison of the hashed confirming verificationrecord to the retrieved verification contract indicating they are atleast a partial match, a session certification token for a decentralizedapplication may be generated. Finally, the procedure may comprisetransmitting the session certification token to the user.

Referring now to FIG. 19, a VTTP+ client-server model is described inmore detail. In the client-server model, VTTP+ works as arequest-response protocol based on a client-server architecture, whereusers 1206, 1200, 1202 use VTTP+ clients 1208, 1209, 1212 to sendrequests 1214, 1204, 1216 to a VTTP+ server 1210, and the server 1210responds to the requests. The server 1210 processes the VTTP+ requests1214, 1204, 1216 and generates and sends transactions 1218, 1220, 1222to participating blockchain networks 1224, participating fiat banks 1226and participating fiat wallets 1228, to execute a value transfer.

Referring now to FIG. 20, a VTTP+ peer-to-peer model is described inmore detail. In the peer-to-peer model, VTTP+ works as a peer-to-peerprotocol where VTTP+ peers 1302, 1314, 1318, 1326 operated by respectiveusers 1300, 1306, 1320, 1330 communicate 1308, 1312, 1328 directly withtheir peers. A VTTP+ coordinator 1316 may be used for coordinating 1310the communication between peers. VTTP+ peers 1302, 1314, 1318, 1326generate and send transactions 1304, 1322, 1324, 1332, 1340, 1342 toparticipating blockchain networks 1334, participating fiat banks 1336and participating fiat wallets 1338, to execute a value transfer.

Referring now to FIG. 21, a VTTP+ intra-entity value transfer process isdescribed in more detail. The VTTP+ intra-entity value transfer processenables transfer of cryptocurrency, tokens or fiat currency from oneaccount to another account on the same entity (such as a participatingblockchain network, participating fiat bank or participating fiatwallet). In the present embodiment, an intra-chain value transferrequest may comprise a User A 1400 wanting to transfer certain units ofa cryptocurrency, tokens or fiat currency from an account on an entity1424 (participating blockchain network, participating fiat bank orparticipating fiat wallet) to the account of another User B 1402 on thesame entity 1424. At step 1 1404, User A 1400 initiates value transferrequest to send cryptocurrency, tokens or fiat currency to User B 1402(e.g. to send 1 ETH from User A to User B, or $1 from user A to user B).At step 2 1410, a VTTP+ client 1406 associated with User A 1400 sends aVTTP+ SEND request to the VTTP+ server 1420. At step 3 1412, the VTTP+server 1420 generates a raw transaction and returns the same in a SENDresponse to the VTTP+ client 1406 for User A 1400. At step 4 1414, UserA 1400 signs the raw transaction with a private key comprised by theVTTP+ client 1406 and the VTTP+ client 1406 sends the VTTP+ SIGNtransaction to the VTTP+ server 1420. At step 5 1422, the VTTP+ server1420 verifies the signature and broadcasts the transaction to the entity1424. At step 6 1416, User A 1400 receives a value transfer notificationvia the VTTP+ client 1406. At step 7 1418, User B 1402 receives a valuetransfer notification via a VTTP+ client 1408 associated with User B1402.

Referring now to FIG. 22, a VTTP+ inter-entity value transfer process isdescribed in more detail. The VTTP+ inter-entity value transfer processenables transfer of cryptocurrency, tokens or fiat currency from anaccount on an entity (such as a participating blockchain network,participating fiat bank or participating fiat wallet) to another accounton a different entity. At step 1 1502, a User A 1500 initiates aninter-entity value transfer request to a User B 1504 (e.g. to send 1 ETHfrom user A to user B who receives the value in equivalent number ofUSD). At step 2 1510, a VTTP+ client 1506 associated with User A 1500sends a VTTP+ SEND request to a VTTP+ server 1520. At step 3 1512, theVTTP+ server 1520 generates a raw transaction and returns the same in aSEND response to the VTTP+ client 1506. At step 4 1514, User A 1500signs the raw transaction with a private key comprised by the CTTP+client 1506 and the VTTP+ client 1506 sends the VTTP+ SIGN transactionto the VTTP+ server 1520. At step 5 1528, the VTTP+ server 1520 verifiesthe signature and broadcasts the transaction to the entity-1 1532. Atstep 6 1522, when the value transfer from an account associated withUser A 1500 on entity-1 1532 to a Vault account on entity-1 1532 isconfirmed, the cryptocurrency, tokens or fiat currency are sent to aCryptocurrency/Token/Fiat Exchange account 1526. At step 7 1524,cyptocurrency, tokens or fiat currency are exchanged. At step 8 1530,the exchanged cyptocurrency, tokens or fiat currency are sent to anaccount associated with User B 1504 on entity-2 1534. At step 9 1516,User A 1500 receives a value transfer notification via the VTTP+ client1506. At step 10 1518, User B 1504 receives a value transfernotification via a VTTP+ client 1508 associated with User B 1504.

Referring now to FIG. 23, an exemplary VTTP+ server architecture, isdescribed in more detail. A VTTP+ server 1600 may have one or more VTTP+Workers 1602 that are individual services to process VTTP+ requests andexecute the VTTP+ commands sent by VTTP+ clients. The VTTP+ server 1600may further comprise a VTTP+ API 1616 that allows the participatingblockchain networks 1628, participating fiat banks 1630 andparticipating fiat wallets 1632 to use VTTP+ protocol for exchange ofvalue. A separate blockchain network 1634 may be positioned incommunication 1620 with the VTTP+ server 1600 and used for user identityand access management. The VTTP+ server 1600 may further compriseadditional services, such as a User Identity & Access Management Service1612, an Authentication & Authorization Service 1608, and an Analytics &Reporting Service 1614. The VTTP+ server 750 may further comprise inter-and intra-entity messaging services 1610 and connectors for databases,cloud services, fiat bank networks, fiat wallet networks & blockchainnetworks 1618. A transactions filter 1604 may be comprised by the server1600 for filtering transactions. The server 1600 may use various SmartContracts 1606 to bolster security. These smart contracts 1606 may beexecuted for each VTTP+ request and perform additional verification(such as verifying sender and receiver's address). The smart contractsmay enforce checks such as time limits or quantity restrictions. Somesmart contracts may perform functions similar to virus filters, forfiltering out suspicious transactions. New smart contracts can bedistributed to VTTP+ servers in a manner similar to virus updates.

Referring now to FIG. 24, an exemplary VTTP+ reference architecture isdescribed in more detail. Users 1700 may use VTTP+ clients 1702, 1704 tocommunicate with VTTP+ servers 1710, 1712, 1714 through an API gateway1706. The VTTP+ servers 1710, 1712, 1714 sit under a load balancer 1708and expose a number API endpoints. The API gateway 1706 makes these APIsavailable to the VTTP+ clients 1702, 1704. Each API has an endpoint (forexample, vttps://example.com/ethereum) and a set of VTTP+ methods orcommands which are supported for the endpoint (such as GET, SEND,REQUEST, etc.). The API gateway 1706 may use an API key to enableauthentication for APIs. The API gateway 1706 may also performadditional functions such as logging each API request and rate-limitingof requests. A separate relational (SQL) or non-relational (NoSQL)database 1728 may be used to store data such as user credentials andapplication specific data. Each VTTP+ server 1710, 1712, 1714 isconnected to all participating blockchain networks 1730, participatingfiat banks 1732 and participating fiat wallets 1734.

Referring now to FIG. 25, an illustration of an exemplary scenario ofvalue transfer between two networks which use common universal tethertokens is described in more detail. A first blockchain network XX 1800uses an in-network token xx 1804 and a tether token 1808, where thein-network token xx 1804 can be exchanged 1806 for the tether token1808. A second blockchain network YY 1802 uses an in-network token yy1814 and a tether token 1810, where the in-network token yy 1814 can beexchanged 1812 for the tether token 1810. The tether tokens 1808 and1810 used in the two networks 1800 and 1802 is the same. The commontether token 1808, 1810 may be tethered to a stable fiat currency likeUSD which is external to blockchain networks XX and YY 1800, 1802.Current cryptocurrency exchanges use a tether token such as USD Tether(USDT) and a user can sell any cryptocurrency/token and convert to USDTand then use it to get any other cryptocurrency/token on the sameexchange. However, current cryptocurrency exchanges don't allow transferof the tether token (such as USDT) from one exchange to another. A usercan sell a cryptocurrency/token (such as BTC) on a first exchange to getUSDT but the user cannot transfer USDT to a second exchange to buyanother cryptocurrency/token (such as ETH). The use of a common tethertoken and VTTP/VTTP+ enables exchange of tokens 1816 between differenttoken networks. The cost per in-network token transaction is very low(near zero), and conversion of tether to fiat is only done infrequentlybased on a time period or a certain number of transactions.

Referring now to FIG. 26, an illustration of an exemplary scenario ofvalue transfer between two networks which use different tether tokens,is described in more detail. A first blockchain network XX 1900 uses anin-network token xx 1904 and a tether token 1908, where the in-networktoken xx 1904 can be exchanged 1906 for the tether token 1908. A secondblockchain network YY 1902 uses an in-network token yy 1914 and a tethertoken 1910, where the in-network token yy 1914 can be exchanged 1912 forthe tether token 1910. The tether tokens 1908 and 1910 used in the twonetworks 1900 and 1902 are different. The use of different tether tokensand VTTP/VTTP+ enables exchange of tokens between different tokennetworks. This different tether token approach may be beneficial wherethe blockchain networks XX and YY 1900, 1902 operate in differentcountries and national governments require local tether tokens so thatmoney can't leave the borders to provide local guarantees for safety ofconsumers. Accordingly, in some embodiments, tether token 1908 may betethered to a first fiat currency and tether token 1910 may be tetheredto a second fiat currency different from the first fiat currency.Moreover, as a result of tether token 1910 being tethered to a secondfiat currency, the value of the tether token 1910 may be expressed interms of the first fiat currency that is proportionate to the conversionratio between the first and second fiat currencies. In the presentexample, the tether token 1910 has a conversion ratio of 0.5 per 1 USD.The cost per in-network token transaction is very low (near zero), andconversion of tether to fiat is only done infrequently based on a timeperiod or a certain number of transactions.

Referring now to FIG. 27, an illustration of an exemplary scenario ofaggregation of in-network tokens is described in more detail. In theembodiment shown in FIG. 27, there are four users. The presentembodiment describes individual in-network transactions between users.The users Tom, Mary, Joe, and Jerry may each have user account addresseson a blockchain network that uses the in-network tokens. A plurality oftransaction requests may be received, with each transaction actioncomprising a sending user account address, a receiving user accountaddress, and a transaction value expressed in terms of a quantity ofin-network tokens. The transactions may each have an associatedtransaction request smart contract recorded to the blockchain network,defining a plurality of transaction request smart contracts. FIG. 27depicts the transactions with receiving user account addresses 2000,2002, 2004, 2006 and sending user account addresses 2008, 2010, 2012,2014 for the users. A first transaction request 2020 may comprise Joe2012 as the sending user account address, Tom 2000 as the receiving useraccount address, and a transaction amount of three in-network. A secondtransaction request 2022 may comprise Joe 2012 as the sending useraccount address, Mary 2002 as the receiving user account address, and atransaction amount of 6 in-network tokens. A third transaction request2024 may comprise Tom 2008 as the sending user account address, Mary2002 as the receiving user account address, and a transaction amount offour in-network tokens. A fourth transaction request 2026 may compriseJerry 2014 as the sending user account address, Joe 2004 as thereceiving user account address, and a transaction amount of 7 in-networktokens. A fifth transaction request 2028 may comprise Joe 2012 as thesending user account address, Jerry 2006 as the receiving user accountaddress, and a transaction amount of 9 in-network tokens. Each user'saggregation account values are calculated in tethered tokens as shown,for instance, with Joe having a net debit of 11 in-network tokens thatis converted to a value of 5.5 negative (or debited) tethered tokens,based on a conversion ratio of 2 in-network tokens for one tetheredtoken). Determination of aggregation account value results in some useraccount addresses having a net credit, defining a credit user accountaddress, and other user account addresses having a net debit, definingdebit user account addresses. The aggregation of transactions may berecorded to an aggregate transaction record. Such a record may berecorded in a smart contract on the blockchain network. In someembodiments, the aggregate transaction record smart contract maycomprise an address for each smart contract associated with theplurality of transaction requests. Prior to processing each transactionrequest, a balance check procedure may be performed do determine if eachuser account has a present permitted transaction amount that issufficient to cover a debit of tokens as indicated in the transactionrequest. If there is a present permitted transaction amount of 15in-network tokens for Joe, he is still allowed to “spend” 18 in-networktokens since he is credited 7 tokens from Jerry, bringing his updatepermitted transaction amount to 11 at the time the entire set ofin-network tokens is synchronized into tethered tokens as an aggregatedbatch. The execution of the net transaction amount may occur uponreaching an aggregation threshold, that may be based on time, such apredefined length of time since a previous net transaction execution,value periods, a gross transaction amount (i.e. the total value of eachtransaction), or a risk tolerance based upon at least one of theconversion ratio, the net transactions, the present permittedtransaction amount of one, some, or all of the user account addresses,or combinations thereof. The net transaction may be recorded to a nettransaction smart contract on the blockchain network. Further, shouldthere be tax or other implications for certain individual in-networktransactions, or transaction costs, smart contracts will calculate taxesand/or transaction costs for individual in-network transactions andstore them on the blockchain for retrieval and analysis. The VTTPservices can monitor dynamic behavior of the users and the transactionsand collection statistical data that may be used to adjust the periodover which aggregation may take place, or its frequency based on thevolume of the transactions and their relative amounts in a manner tominimize transaction costs (primarily through conversions to fiatcurrency, if any). Further transaction limits in terms of amounts oftokens permitted for each user may also be based on the statisticscollected to ensure that risk is minimized. These analyticsfunctionalities may assist the operators of the exchanges and VTTPservices to maximize throughput and efficiency while minimizing risk andimproving their cost and revenues.

In some embodiments, where a sending user account address is determinedto not have a present permitted transaction amount greater than atransaction amount of a transaction request, the transaction request maybe re-processed, including a redetermination of if the transaction valueis greater than the present permitted transaction amount of the sendinguser account address after at least one of a first time interval and anintervening transaction including the sending user account address. Suchre-processing may be defined as a transaction retry. There may be one ormore transaction retry attempts. In some embodiments, there may be alimit to transaction retry attempts based on a fixed number of attemptsor a second time interval measured from the original transaction requestor the first transaction retry attempt.

Referring now to FIG. 28, an illustration of an exemplary scenario ofaggregation of transactions across two token networks, is described inmore detail. As noted in FIG. 28, in this embodiment there are fiveusers, where the fifth user belongs to a second and different blockchainnetwork that has a different second tethered token. A transactionrequest 2070 comprising Mary 2062 as the sending user account addressand user Alexis 2058 as the receiving user account address on the secondblockchain ratio, and a transaction amount of 12 first in-networktokens. An amount of first in-network tokens equal in value to the netcredit to Alexis 2058, defining a net credit value, may be exchanged foran amount of first tethered tokens having a value equal to the netcredit value. The first tethered tokens resulting from this exchange maybe comprised by a first tethered token transfer record that may berecorded to the first blockchain network. A transaction of sending thetokens comprised by the first tethered token transfer record to atethered token exchange may be recorded to the first blockchain network,similar to the procedure shown in FIG. 22. The first tethered tokens maybe exchanged for an amount of second tethered tokens having a valueequal to the net credit value. The second tethered coins resulting fromthe exchange may be comprised by a second tethered token transferrecord. A transaction of receiving the tokens comprised by the secondtethered token transfer record at the second blockchain network from thetethered token exchange may be recorded to the second blockchainnetwork. Subsequently, the tokens comprised by the second tethered tokentransfer record may be exchanged on the second blockchain network for anamount of second in-network tokens having a value equal to the netcredit value. The second in-network tokens resulting from this exchangemay be defined as a second blockchain network deposit. The tokens of thesecond blockchain network deposit may then be deposited to the useraccount address on the second blockchain network associated with Alexis.The conversion ratio of the first tethered token in the first blockchainnetwork to a second tethered token in a second blockchain network in thepresent embodiment is two to one. As noted, for user Alexis 2058 on thesecond blockchain network, there is a credit to her account of 3 secondtethered tokens. assuming a ratio of 2 first tethered tokens of thefirst blockchain network being exchanged for one second tethered tokenon the second blockchain network. Accordingly, the first in-networktoken may have a first exchange rate with the first tethered token, thesecond in-network token may have a second exchange rate with the secondtethered token, and the first tethered token may have a third exchangerate with the second tethered token.

In some embodiments, where a transaction request requires a conversionbetween two tethered tokens that are tethered to different fiatcurrencies, the present permitted transaction amount may be updated toreflect additional risk in the transaction resulting from the multipleexchange rates involved.

FIG. 29 shows an illustration of the result of an exemplary scenario ofaggregation of transactions across two token networks in terms of thetethered tokens after suitable conversions. One may also considerembodiments that may modify the way the aggregation is done within thenetwork and across the network, for instance, by operating on in-networktokens themselves, as opposed to converting to tethered tokens, shouldthe business context be suitable for elimination of tethered tokens. Theclaims will determine the scope of our inventions, which may cover oneor more of the embodiments discussed.

Some of the illustrative aspects of the present invention may beadvantageous in solving the problems herein described and other problemsnot discussed which are discoverable by a skilled artisan.

While the above description contains much specificity, these should notbe construed as limitations on the scope of any embodiment, but asexemplifications of the presented embodiments thereof. Many otherramifications and variations are possible within the teachings of thevarious embodiments. While the invention has been described withreference to exemplary embodiments, it will be understood by thoseskilled in the art that various changes may be made and equivalents maybe substituted for elements thereof without departing from the scope ofthe invention. In addition, many modifications may be made to adapt aparticular situation or material to the teachings of the inventionwithout departing from the essential scope thereof. Therefore, it isintended that the invention not be limited to the particular embodimentdisclosed as the best or only mode contemplated for carrying out thisinvention, but that the invention will include all embodiments fallingwithin the scope of the appended claims. Also, in the drawings and thedescription, there have been disclosed exemplary embodiments of theinvention and, although specific terms may have been employed, they areunless otherwise stated used in a generic and descriptive sense only andnot for purposes of limitation, the scope of the invention therefore notbeing so limited. Moreover, the use of the terms first, second, etc. donot denote any order or importance, but rather the terms first, second,etc. are used to distinguish one element from another. Furthermore, theuse of the terms a, an, etc. do not denote a limitation of quantity, butrather denote the presence of at least one of the referenced item.

Thus the scope of the invention should be determined by the appendedclaims and their legal equivalents, and not by the examples given.

The claims in the instant application are different than those of theparent application or other related applications. Applicant thereforerescinds any disclaimer of claim scope made in the parent application orany predecessor application in relation to the instant application. Anysuch previous disclaimer and the cited references that it was made toavoid, may need to be revisited. Further, any disclaimer made in theinstant application should not be read into or against the parentapplication.

1. A blockchain value transfer method comprising: receiving a pluralityof transaction requests, each transaction request comprising a sendinguser account address, a receiving user account address, and atransaction value expressed in terms of a quantity of first in-networktokens, the user account addresses being addresses on a blockchainnetwork; performing a balance check procedure on each transactionrequest comprising: identifying a present permitted transaction amountin first in-network tokens for the sending user account address;determining if the transaction value in first in-network tokens isgreater than the present permitted transaction amount of the sendinguser account address; upon determining the transaction value in firstin-network tokens is greater than the present permitted transactionamount in first in-network tokens of the sending user account address,refusing the transaction; upon determining the transaction value is notgreater than the present permitted transaction amount of the sendinguser account address, adding the transaction request to an aggregatetransaction record; updating the present permitted transaction amount ofthe sending user account address reflecting a debit of the transactionvalue; and updating the present permitted transaction amount of thereceiving user account address reflecting a credit of the transactionvalue; determining a net transaction amount for each user accountaddress for each transaction in the aggregate transaction record, withthe transaction value for transactions including the user accountaddress as the sending user account address as a debit and as thereceiving user account address as a credit; and executing the nettransaction amount for each user account address associated with the nettransaction amount by transacting tokens to and from the user accountaddresses upon reaching an aggregation threshold, comprising:withdrawing an amount of tokens from user account addresses with a netdebit having a value equal to the value of the net debit, defined asdebit user account addresses, defining debited tokens; and depositing anamount of tokens from the debited tokens to user account addresses witha net credit in an amount equal to the amount of the net credit, definedas credit user account addresses.
 2. The blockchain value transfermethod of claim 1 wherein execution of the net transaction amountcomprises recording a net transaction smart contract to the blockchainnetwork, the net transaction smart contract comprising each of the useraccount addresses and the tokens transacted with each of the useraccount addresses.
 3. The blockchain value transfer method of claim 2wherein the net transaction smart contract adds a transaction fee toeach token transaction for the user account addresses.
 4. The blockchainvalue transfer method of claim 1 wherein the aggregation threshold isdefined as at least one of a length of time elapsing since a previousnet transaction execution, a gross transaction amount, or a risktolerance.
 5. The blockchain value transfer method of claim 1 whereineach transaction request of the plurality of transaction requests has anassociated transaction request smart contract recorded on the blockchainnetwork, defining a plurality of transaction request smart contracts. 6.The blockchain value transfer method of claim 5 wherein each transactionrequest smart contract comprises a transaction tax added to thetransaction value.
 7. The blockchain value transfer method of claim 1further comprising, for each refused transaction, re-determining if thetransaction value in first in-network tokens is greater than the presentpermitted transaction amount of the sending user account address afterat least one of a first time interval and an intervening transactioninvolving the sending user account address, defining a transactionretry, for one or more of a fixed number of transaction retry attemptsor after a second time interval.
 8. The blockchain value transfer methodof claim 1 wherein a first sending user account address of a firsttransaction request of the plurality of transaction requests is on afirst blockchain network comprising the first in-network token; a firstreceiving user account address of the first transaction request is on asecond blockchain network and comprises a second in-network token; thefirst receiving user account address is determined to be a credit useraccount address; and executing the net transaction amount for thereceiving user account comprises: exchanging an amount of firstin-network tokens, equal in value to the net credit for the firstreceiving user account, defining a net credit value, for an amount offirst tethered tokens having a value equal to the net credit value, thefirst tethered tokens being comprised by a first tethered token transferrecord; recording a transaction to the first blockchain network ofsending the first tethered token transfer record from the firstblockchain network to the second blockchain network; recording atransaction to the second blockchain network of receiving the firsttethered token transfer record at the second blockchain network from thefirst blockchain network; exchanging the first tethered tokens comprisedby the first tethered transfer record for an amount of second in-networktokens having a value equal to the net credit value, defining a secondblockchain network deposit; and depositing the second blockchain networkdeposit to the receiving user account address.
 9. The blockchain valuetransfer method of claim 8 wherein: the first tethered token has a valuethereof tethered to a first fiat currency; the first in-network tokenhas a first exchange rate with the first tethered token; and the secondin-network token has a second exchange rate with the first tetheredtoken that is different from the first exchange rate.
 10. The blockchainvalue transfer method of claim 1 wherein a first sending user accountaddress of a first transaction request of the plurality of transactionrequests is on a first blockchain network comprising the firstin-network token; a first receiving user account address of the firsttransaction request is on a second blockchain network and comprises asecond in-network token; the first receiving user account address isdetermined to be a credit user account address; and executing the nettransaction amount for the receiving user account comprises: exchangingan amount of first in-network tokens, equal in value to the net creditfor the first receiving user account, defining a net credit value, foran amount of first tethered tokens having a value equal to the netcredit value, the first tethered tokens being comprised by a firsttethered token transfer record; recording a transaction to the firstblockchain network of sending the first tethered token transfer recordfrom the first blockchain network to a tethered token exchange;exchanging the first tethered tokens comprised by the first tetheredtoken transfer record for an amount of second tethered tokens having avalue equal to the net credit value, the second tethered tokens beingcomprised by a second tethered token transfer record; recording atransaction to the second blockchain network of receiving the secondtethered token transfer record at the second blockchain network from thetethered token exchange; exchanging the second tethered tokens comprisedby the second tethered transfer record for an amount of secondin-network tokens having a value equal to the net credit value, defininga second blockchain network deposit; and depositing the secondblockchain network deposit to the receiving user account address. 11.The blockchain value transfer method of claim 10 wherein: a value of thefirst tethered token is tethered to a first fiat currency; a value ofthe second tethered token is tethered to a second fiat currencydifferent from the first fiat currency; the first in-network token has afirst exchange rate with the first tethered token; the second in-networktoken has a second exchange rate with the second tethered token; and thefirst tethered token has a third exchange rate with the second tetheredtoken.
 12. The blockchain value transfer method of claim 11 furthercomprising at least one of defining the first exchange rate responsive,the second exchange rate, and the third exchange rate responsive to thesecond fiat currency.
 13. The blockchain value transfer method of claim10 further comprising updating the present permitted transaction amountresponsive to at least one of the first fiat currency and the secondfiat currency.
 14. A blockchain value transfer method comprising:receiving a plurality of transaction requests, each transaction requestcomprising a sending user account address, a receiving user accountaddress, and a transaction value expressed in terms of a quantity offirst in-network tokens, the user account addresses being addresses on ablockchain network; performing a balance check procedure on eachtransaction request comprising: identifying a present permittedtransaction amount in first in-network tokens for the sending useraccount address; determining if the transaction value in firstin-network tokens is greater than the present permitted transactionamount of the sending user account address; upon determining thetransaction value in first in-network tokens is greater than the presentpermitted transaction amount in first in-network tokens of the sendinguser account address, refusing the transaction; upon determining thetransaction value is not greater than the present permitted transactionamount of the sending user account address, adding the transactionrequest to an aggregate transaction record; updating the presentpermitted transaction amount of the sending user account addressreflecting a debit of the transaction value; and updating the presentpermitted transaction amount of the receiving user account addressreflecting a credit of the transaction value; determining a nettransaction amount for each user account address for each transaction inthe aggregate transaction record, with the transaction value fortransactions including the user account address as the sending useraccount address as a debit and as the receiving user account address asa credit; and executing the net transaction amount for each user accountaddress associated with the net transaction amount by transacting tokensto and from the user account addresses upon reaching an aggregationthreshold, comprising: recording a net transaction smart contract to theblockchain network, the net transaction smart contract comprising eachof the user account addresses and the tokens transacted with each of theuser account addresses; withdrawing an amount of tokens from useraccount addresses with a net debit having a value equal to the value ofthe net debit, defined as debit user account addresses, defining debitedtokens; and depositing an amount of tokens from the debited tokens touser account addresses with a net credit in an amount equal to theamount of the net credit, defined as credit user account addresses;wherein the aggregation threshold comprises at least one of a length oftime elapsing since a previous net transaction execution, a grosstransaction amount, or a risk tolerance.
 15. The blockchain valuetransfer method of claim 14 wherein a first sending user account addressof a first transaction request of the plurality of transaction requestsis on a first blockchain network comprising the first in-network token;a first receiving user account address of the first transaction requestis on a second blockchain network and comprises a second in-networktoken; the first receiving user account address is determined to be acredit user account address; and executing the net transaction amountfor the receiving user account comprises: exchanging an amount of firstin-network tokens, equal in value to the net credit for the firstreceiving user account, defining a net credit value, for an amount offirst tethered tokens having a value equal to the net credit value, thefirst tethered tokens being comprised by a first tethered token transferrecord; recording a transaction to the first blockchain network ofsending the first tethered token transfer record from the firstblockchain network to the second blockchain network; recording atransaction to the second blockchain network of receiving the firsttethered token transfer record at the second blockchain network from thefirst blockchain network; exchanging the first tethered tokens comprisedby the first tethered transfer record for an amount of second in-networktokens having a value equal to the net credit value, defining a secondblockchain network deposit; and depositing the second blockchain networkdeposit to the receiving user account address.
 16. The blockchain valuetransfer method of claim 15 wherein: the first tethered token has avalue thereof tethered to a first fiat currency; the first in-networktoken has a first exchange rate with the first tethered token; and thesecond in-network token has a second exchange rate with the firsttethered token that is different from the first exchange rate.
 17. Theblockchain value transfer method of claim 14 wherein a first sendinguser account address of a first transaction request of the plurality oftransaction requests is on a first blockchain network comprising thefirst in-network token; a first receiving user account address of thefirst transaction request is on a second blockchain network andcomprises a second in-network token; the first receiving user accountaddress is determined to be a credit user account address; and executingthe net transaction amount for the receiving user account comprises:exchanging an amount of first in-network tokens, equal in value to thenet credit for the first receiving user account, defining a net creditvalue, for an amount of first tethered tokens having a value equal tothe net credit value, the first tethered tokens being comprised by afirst tethered token transfer record; recording a transaction to thefirst blockchain network of sending the first tethered token transferrecord from the first blockchain network to a tethered token exchange;exchanging the first tethered tokens comprised by the first tetheredtoken transfer record for an amount of second tethered tokens having avalue equal to the net credit value, the second tethered tokens beingcomprised by a second tethered token transfer record; recording atransaction to the second blockchain network of receiving the secondtethered token transfer record at the second blockchain network from thetethered token exchange; exchanging the second tethered tokens comprisedby the second tethered transfer record for an amount of secondin-network tokens having a value equal to the net credit value, defininga second blockchain network deposit; and depositing the secondblockchain network deposit to the receiving user account address. 18.The blockchain value transfer method of claim 17 wherein: a value of thefirst tethered token is tethered to a first fiat currency; a value ofthe second tethered token is tethered to a second fiat currencydifferent from the first fiat currency; the first in-network token has afirst exchange rate with the first tethered token; the second in-networktoken has a second exchange rate with the second tethered token; and thefirst tethered token has a third exchange rate with the second tetheredtoken.
 19. The blockchain value transfer method of claim 18 furthercomprising at least one of defining the first exchange rate responsive,the second exchange rate, and the third exchange rate responsive to thesecond fiat currency.
 20. A blockchain value transfer method comprising:receiving a plurality of transaction requests, each transaction requestcomprising a sending user account address, a receiving user accountaddress, and a transaction value expressed in terms of a quantity offirst in-network tokens, the user account addresses comprising: a firstsending user account address of a first transaction request of theplurality of transaction requests on a first blockchain networkcomprising the first in-network token; and a first receiving useraccount address of the first transaction request is on a secondblockchain network and comprises a second in-network token; performing abalance check procedure on each transaction request comprising:identifying a present permitted transaction amount in first in-networktokens for the sending user account address; determining if thetransaction value in first in-network tokens is greater than the presentpermitted transaction amount of the sending user account address; upondetermining the transaction value in first in-network tokens is greaterthan the present permitted transaction amount in first in-network tokensof the sending user account address, refusing the transaction; upondetermining the transaction value is not greater than the presentpermitted transaction amount of the sending user account address, addingthe transaction request to an aggregate transaction record; updating thepresent permitted transaction amount of the sending user account addressreflecting a debit of the transaction value; and updating the presentpermitted transaction amount of the receiving user account addressreflecting a credit of the transaction value; determining a nettransaction amount for each user account address for each transaction inthe aggregate transaction record, with the transaction value fortransactions including the user account address as the sending useraccount address as a debit and as the receiving user account address asa credit, with the first receiving user account address being determinedto be a credit user account address; and executing the net transactionamount for each user account address associated with the net transactionamount by transacting tokens to and from the user account addresses uponreaching an aggregation threshold, comprising: withdrawing an amount offirst in-network tokens from user account addresses with a net debithaving a value equal to the value of the net debit, defined as debituser account addresses, defining debited tokens; and exchanging anamount of first in-network tokens, equal in value to a net credit forthe first receiving user account, defining a net credit value, for anamount of first tethered tokens having a value equal to the net creditvalue, the first tethered tokens being comprised by a first tetheredtoken transfer record; recording a transaction to the first blockchainnetwork of sending the first tethered token transfer record from thefirst blockchain network to a tethered token exchange; exchanging thefirst tethered tokens comprised by the first tethered token transferrecord for an amount of second tethered tokens having a value equal tothe net credit value, the second tethered tokens being comprised by asecond tethered token transfer record; exchanging the second tetheredtokens comprised by the second tethered transfer record for an amount ofsecond in-network tokens having a value equal to the net credit value,defining a second blockchain network deposit; depositing the secondblockchain network deposit to the receiving user account address; anddepositing the remaining first in-network tokens from the debited firstin-network tokens to user account addresses on the first blockchainnetwork with a net credit in an amount equal to the amount of the netcredit, defined as credit user account addresses.